# Architectural Design for Deep Learning Networks

## Relevant literature
- ISO 42010, System and software engineering, 2011
	- Update in progress (2020), see (http://www.iso-architecture.org/42010/index.html)
- ISO 15704, Industrial automation systems, 2000 (really??)
- See also NGEA report Deliverable D2.1. and D2.2

## From "The 4+1 view model of software architecture"

### Introduction
- It must be clear what the architecture represents: Is it data flow? Control flow? Source code? 
> "Authors have struggled hard to represent more on one blueprint than it can actually express"
- Architecture of software design should not *suffer* from premature partitioning due to the system design.

### What is an architectural model
- Assembly of a number of architectural elements in some *well-chosen* forms to satisfy *major* functional - and non-functional requirements.
- A model of **multiple views/perspectives**:
	1. Logical view: Object model of the design;
	2. Process view: Concurrency and synchronisation aspects;
	3. Physical view: Mapping of software onto hardware, software distribution on hardware;
	4. Development view: Static organisation of the software in its development environment.
> Organised around these four views, and *illustrated* by a few *selected* use cases, or scenarios, which become a **fifth view**.

### Logical architecture
- Primarily supports the **functional requirements**. 
- System is decomposed into a set of key abstraction called *objects* or *object classes*.
- Aim is to identify common mechanisms and design elements across various parts of the system.
> For data-driven application one may use *entity relationship* diagrams. 

### Process architecture
- Takes non-functional requirements into account.
- Addresses concurrency, fault-tolerance, and distribution. 
- Assigns execution of an operations for an object to thread of control. 
	1. On the highest level the process architecture is a set of independently executing logical network of *processes* which communicate with each other. They are distributed across a set of connected hardware resources. A *process* is a grouping of tasks that form an executable unit. 
	2. Multiple logical networks may exist simultaneously, sharing the resources. 
	3. The software is partitioned into a set of independent *tasks*. A *task* is a separate thread of control, that can be scheduled individually on one processing node.
	4. Flow of messages and process loads can be estimated based on the process blueprints. 
	
### Development architecture
- It is a system decomposition: The software is packaged in small chunks (subsystems, or libraries) that can be developed by a team. 
- Subsystems are organised in a hierarchy of *layers*, where each layer provides a well-defined interface to the layers above it. 
> The complete development architecture can only be described when all the elements of the software have been idetified. 
- The following rules govern the development architecture: 
	1. Partitioning,
	2. Grouping,
	3. Visibility.

### Physical architecture
- Primarily takes the non-functional requirements into account. 
- Maps various elements such as networks, processes, tasks, and objects onto various nodes. 
- The mapping of the software to the nodes is highly flexible. 

### The +1 view: Scenarios
- A small set of *general use cases*, or *scenarios*, show ho the four architectural views work seamlessly together. 
- The *scenarios* are an abstraction of the most important requirements. 
- They serve two purposes: 
	1. As a driver to discover the architectural elements during the architecture design. 
	2. As a validation and illustration role.
